The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In the context of event-based information systems, an event is represented by event data that defines one or more attributes of a detected condition, for triggering an information to be sent, i.e., an event. For example, event data may define the type of condition that was detected, as well as a time at which the condition was detected.
Most event-based information systems include some type of event processing mechanism for processing event data and determining what actions, if any, are to be performed in response to events. Event processing mechanisms typically include built-in or “hard coded” logic that specifies one or more actions to be taken in response to the occurrence of a particular event. Event processing mechanisms may themselves perform a specified action. Sometimes, event processing mechanisms notify other software applications that an event has occurred so that the other software applications may act on the event. For example, an event processing mechanism may notify a network management software application, executing at a Network Operations Center (NOC), that an event has occurred to allow the network management software to notify administrative personnel of the existence of an event, e.g., through a Graphical User Interface (GUI).
One important aspect of event processing is event cancellation, upon a condition has been considered either solved or pending. Event cancellation refers to situations where an event processing mechanism determines that an event is to be cancelled, instead of being acted on or reported to another entity, such as a higher software layer in a hierarchical system. Canceling an event may also involve an event processing mechanism requesting that the source of the event, i.e., the entity that generated and provided the event data to the event processing mechanism, cancel the event. The source mechanism may then clear the event in response to the request, for example by deleting a record of the event from its local storage.
Event cancellation may occur for a variety of reasons, depending upon the requirements of a particular application. Sometimes, the condition that was the basis of an event may have changed and is no longer valid for the event. Some events become subordinate to other events with higher priorities, which when processed, make it unnecessary to process the subordinate events. Other events are automatically canceled by an event processing mechanism after a specified amount of time has elapsed from the time the event occurred (so-called “by default” cancellation).
One of the significant issues with conventional event processing is that the criteria used for determining when an event is to be canceled are often embedded or “hard coded” into the processing logic of event processing mechanisms. For example, a set timer may be used to cancel “old” events after a specified period of time. As another example, certain type of events may be cancelled under specified conditions. This type of implementation causes two types of problems.
First, embedded cancellation criteria are generally inflexible and do not work well in dynamic computing environments. For example, one of the most common event cancellation criteria employed is time expiration, which although is relatively straightforward to implement, is not well suited for a large number of applications, as the source of an event may not have a complete view on the state of the entire system. Many applications may require event cancellation policies that are specific to a particular context or customer and are therefore not easily implemented in an embedded event cancellation environment.
Second, it can be difficult to change event cancellation criteria that have been embedded into the processing logic of event processing mechanisms. When a change is required, the event processing mechanisms that need to be updated have to be identified, which may be a complex task. Some distributed computing systems may have thousands of instances of event processing mechanisms that need to be examined. Then the identified event processing mechanisms have to be updated and verified, which may consume a considerable amount of manual resources.
Based upon the foregoing, there is a need for an approach for canceling events that does not suffer from the limitations in prior approaches. There is a particular need for an approach for canceling events that is more flexible in determining whether events are to be canceled.